The present invention relates to the general field of telecommunications.
It relates more particularly to managing the handover between two access networks connected to a core network of a communication (or a call in the general meaning of the term) set up by a terminal over one of the access networks.
The term “communication” is used herein to designate any multimedia data exchange between two terminals and managed via the core network, such as for example a telephone call or a video conference. In the meaning of the invention, a call is constituted firstly by the media session (i.e. media stream) conveying the multimedia data being exchanged, and secondly the communication signaling (i.e. the call signaling) needed for exchanging the data.
The invention applies in preferred but non-limiting manner when the core network is an IP network based on an IP multimedia subsystem (IMS) architecture and using a signaling protocol of the session initiation protocol (SIP) type.
Most telecommunications operators are nowadays beginning to migrate their circuit switched (CF) telephone networks to packet switched (PS) IP core networks, such as for example voice-over IP networks.
In packet-switched networks, a given terminal, providing it is multimode (and/or multiband), may be connected to and registered with the IP core network via a plurality of accesses, such as a third-generation (3G) access network, a set of x digital subscriber line (xDSL), an evolved packet core (EPC) network, a wireless local area network (WLAN), a worldwide interoperability for microwave access (WiMax) network, etc.
A multimode terminal makes it possible for its user to select a network from among the various access networks that are compatible with the terminal for the purpose of setting up a communication. The selection criteria applied generally relate to the user or to the operator of the IP core network: operator charging policy, quality of communication, available bandwidth, etc.
The terminal also makes it possible for the user to hand over an ongoing communication from one access network (an “initial” network) to another access network (a “target” network) if, for example, the quality of transmission on the initial access network becomes poor. This is referred to as communication handover between the initial access network and the target access network, or indeed as PS-PS mobility. This handover may apply to some or all of the media streams associated with the communication and/or the signaling: there is then said to be total or partial transfer of the communication.
In order to guarantee continuity of service while the communication is being handed over and in order to make this operation transparent for the user, mechanisms have been defined for the IMS architecture in the documents 3GPP TS23.237 and TS24.237 (IP multimedia subsystem service continuity; stage 2, and IP multimedia subsystem service continuity, stage 3). These handover mechanisms rely on a dedicated application server known as a service centralization and continuity application server (SCC-AS) in the IMS network being engaged for the purpose of managing the signaling received from the terminal during the handover. FIG. 1 is a diagram of the operation of such a server.
In the example shown in FIG. 1, a terminal T1 is a two-mode terminal connected to and registered with an IP core network on two packet-switched access channels ANA and ANB. The IP core network has IMS architecture and it relies in particular on proxy-call session control function (P-CSCF) servers PA and PB, on a serving-call session control function (S-CSCF) server, on a telephone application server (TAS), and on a service centralization and continuity application server (SCC-AS) as defined in the documents 3GPP TS23.237 and TS24.237.
It is assumed that the terminal T1 has set up a communication with the terminal T2 over the network ANA. This communication is anchored at the server SCC-AS with corresponding media session information.
In accordance with document TS24.237, in order to cause this communication to be handed over from the access network ANA to the access network ANB, the terminal T1 sends an INVITE request over the network ANB containing the information about the media session associated with the communication over ANB (i.e. the characteristics of the media streams reserved for the communication over ANB) (step E10).
This INVITE request satisfies various constraints set by the standard (and described for example in the following documents: 3GPP TS24.229, IETF RFC 5627, IETF RFC 3891, and IETF RFC 4538), and relating in particular:                to the content of its uniform resource identifier (URI); and        to the presence of a “replaces” or a “target-dialog” header (as defined in documents RFC 3891 and RFC 4538), containing the references of the communication set up over the network ANA.        
The INVITE request sent by T1 is conventionally relayed by the server PB to the server S-CSCF (step E20), and then routed by the server S-CSCF to the server SCC-AS (step E30).
On the basis of the information contained in the “replaces” or “target-dialog” header, the server SCC-AS sets up a correlation between the INVITE request and the communication set up between the terminals T1 and T2 over the access network ANA. It then interprets the INVITE request as a request to hand over the communication from the network ANA to the network ANB, and it updates the session information relating to the communication with the information contained in the request.
Thereafter it transmits a re-INVITE request containing this information to the terminal T2 (steps E40-E80).
Thereafter, numerous exchanges of signaling are performed by the server SCC-AS and by the terminals T1 and T2 to cause the communication to be handed over to ANB, and in particular to cause the media streams associated with the communication to be handed over (steps E90-E110). All of this signaling passes through and is processed by the server SCC-AS.
Thus, the handover solution presently proposed in the 3GPP standard is expensive and complex both in the IP core network and in the terminals.
In order to be capable of performing that technique, the terminals must comply with several standards relating in particular to how to construct the handover INVITE request (for example in order to comply with all of the standardized options, they must be capable of including both the “replaces” and the “target-dialog” headers).
In the core network, that solution requires a dedicated application server SCC-AS to be engaged for managing the signaling received from the terminals via the different access networks.
However, it is known that engaging a plurality of application servers, and a fortiori a dedicated server for managing a service, is expensive in terms of resources and processing for the server S-CSCF. This triggering also generates large amounts of signaling exchanges within the network, which phenomenon is amplified by the numerous exchanges needed between the terminals and the SCC-AS server.